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1 Introduction 


This document describes a standard data format for the archival and transport of 
X-ray events generated by ray trace models. Upon review and acceptance by the 
AXAF Software Systems Working Group (SSWG), this standard shall become the 
official AXAF data format for ray trace events. 

The Flexible Image Transport System (FITS) [1 , 2] is well suited for the purposes 
of the standard and has been selected to be the basis of the standard. FITS is both 
flexible and efficient and is also widely used within the astronomical community 
for storage and transfer of data. In addition, software to read and write FITS 
format files are widely available. 

In selecting quantities to be included within the ray trace standard, the AXAF 
Mission Support team, Science Instruments team, and the other contractor teams 
were surveyed. From the results of this survey, the following requirements were 
established: 


• For the scientific needs, each photon should have associated with it: posi- 
tion, direction, energy, and statistical weight. The standard must also ac- 
commodate path length (relative phase), and polarization. Double precision 
is needed for all these quantities. 

• A unique photon identifier is necessary for bookkeeping purposes. 

• A log of individuals, organizations, and software packages that have modified 
the data must be maintained in order to create an audit trail. 

• A mechanism for extensions to the basic kernel should be provided. 

• The ray trace standard should integrate with future AXAF data product 
standards. 


2 The Ray Trace Standard 


The AXAF ray trace standard is based upon the Binary Table Extension to FITS. 
The FITS file structure shall consist of the following: 


• Primary Array Header (with a NULL primary array). 

• RAYTRACE Binary Table Extension Header. 

• RAYTRACE Data. 
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Keyword 

Value 

Description 

SIMPLE 

T 

FITS mandatory 

BITPIX 

8 

FITS mandatory 

NAXIS 

0 

FITS mandatory 

EXTEND 

T 

FITS mandatory 

CONTENT 

’SIMULATION’ 

Identifies file as the result of simulation 

ORIGIN 

char 

The organization generating the FITS file 

OBSERVER 

char 

The person generating the ray trace 

DATE 

’dd/mm/yy’ 

Date the FITS file was created 

TELESCOP 

char 

Name of telescope model used 

PROGNAME 

char 

Name of simulation software used 

OBJECT 

char 

name of observed object 

DATE-OBS 

’dd/mm/yy’ 

U.T. simulation was done 

TIME-OBS 

’hh:mm:ss’ 

U.T. simulation was done 

HISTORY 

comments 

Each software module shall append a history 
line with its version and parameters 

END 


FITS mandatory 


Table 1: Primary Header keywords required by the AXAF ray trace standard 

The Primary Array Header shall contain all history and logging information asso- 
ciated with the data stored. All the information associated with individual photon 
events shall be stored in the RAYTRACE binary table extension. 


2.1 Primary Header 

Table 1 summarizes the FITS primary header keywords required by the AXAF 
ray trace standard. An example of both a primary and secondary header is given 
in Appendix B. The keywords required for the AXAF ray trace standard have 
been chosen from standard FITS reserved keywords and keywords in common use 
within the astronomical community. 


2.1.1 Primary Header Required Keywords 

The following keywords are required by FITS: 


SIMPLE is required to be the first keyword and have logical value T to signify 
this file as a conforming FITS file. 

BITPIX is required to be the second keyword. For AXAF ray trace, it has a 
value of 8 signifying eight bit bytes. 
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NAXIS is required to be the third keyword. For AXAF ray trace, it has a value 
of 0 signifying no data in the primary data array. 

EXTEND is required to have a logical value T to signify that FITS extensions 
follow the primary data array. 

END is required to be the last keyword of the primary header. 


The remaining keywords described in this section are required by the AXAF ray 
trace standard in order to provide a description of the data file. It is important that 
these keywords be maintained so that each data file contains information about its 
own content and history. As much as possible, these keywords have been chosen 
from keywords currently in common use. 


CONTENT shall contain the string ‘SIMULATION’. The keyword identifies the 
FITS file as containing simulated data. Files in FITS format containing 
SIMULATION data may encompass data products from simulated science 
instruments as well as from ray trace models. 

ORIGIN shall contain a string identifying the organization creating the FITS 
file. The keyword is a FITS reserved keyword. 

OBSERVER shall contain a string identifying the person generating the ray 
trace. The keyword is a FITS reserved keyword. 

DATE, DATE-OBS, TIME-OBS the DATE field shall contain the date the 
FITS file was created. The DATE-OBS, and TIME-OBS traditionally refer 
to date and time of observation; for ray trace, they will refer to the date and 
time of the original simulation. By FITS convention, dates and times are 
specified as ’dd/mm/yy’ and ’hh:mm:ss’ in Universal Time. 

TELESCOP shall specify the name of the telescope model used for the ray trace. 

PROGNAME shall specify the name of the ray trace program. 

OBJECT shall specify the object modeled (e.g., ‘POINT SOURCE’). 

HISTORY this keyword may be repeated and is used to log transformations 
on the data. The AXAF ray trace standard requires each software package 
which operates on the data to append a HISTORY line with the name and 
version of the software package, the date, the user, and a statement of the 
parameters used. This line may be continued on multiple HISTORY lines 
by using a backslash (\) character as the last non-blank character in a line 
to be continued. A full description of formats in current use is included in 
Appendix C. 
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Keyword 

Value 

Description 

XTENSION 

’BINTABLE’ 

FITS mandatory 

BITPIX 

8 

FITS mandatory 

NAXIS 

2 

FITS mandatory 

NAXIS1 

int 

FITS mandatory, bytes per row 

NAXIS2 

int 

FITS mandatory, rows in data array 

EXTNAME 

’RAYTRACE’ 

Identifies data as result of ray tracing 

RTVER 

1 

Identifies version of raytrace standard 

ORIGIN 

char 

The organization generating the FITS file 

OBSERVER 

char 

The person generating the ray trace 

TELESCOP 

char 

Name of telescope model used 

PROGNAME 

char 

Name of simulation software used 

OBJECT 

char 

name of observed object 

DATE-OBS 

’dd/mm/yy’ 

U.T. simulation was done 

TIME-OBS 

’hh:mm:ss’ 

U.T. simulation was done 

PCOUNT 

0 

FITS mandatory 

GCOUNT 

1 

FITS mandatory 

TFIELDS 

int 

fields per row 

TTYPEn 

char 

Name of field n 

TFORMn 

char 

Data type of field n 

TUNITn 

char 

Physical units of field n 

END 


FITS mandatory 


Table 2: Secondary Header keywords required by the AXAF ray trace standard 
2.1.2 Primary Header Optional Keywords 

The AXAF ray trace standard defines no optional keywords for the primary header. 


2.2 Raytrace Extension Header 


Table 2 summarizes the FITS secondary header keywords required by the AXAF 
ray trace standard. These keywords define a data array conforming to the binary 
table extension of FITS. 

A FITS binary table can be thought of as a table of rows and columns. For the 
AXAF ray trace standard, there shall be one row for every ray. A description of 
the named columns (or fields) is given in Section 2.3 and for an example of both a 
primary and secondary header see Appendix B. 
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2.2.1 RAYTRACE Required Keywords 


The following keywords are required by the FITS binary table extension standard: 


XTENSION is required to be the first keyword and contain the string ‘BINTABLE’ 
signifying conformance with the binary table extension. 

BITPLX is required to be the second keyword and to have a value of 8 signifying 
eight bit bytes. 

NAXIS is required to be the third keyword. For binary table extensions it has a 
value of 2. 

NAXIS 1 is required to be the fourth keyword. It has an integer value specifying 
the number of bytes needed for each row of data. 

NAXIS2 is required to be the fifth keyword. It has an integer value specifying 
the number of rows (or photon events) in the data array. 

PCOUNT is required to have an integer value of 0. 

GCOUNT is required to have an integer value of 1. 

END is required to be the last keyword of the binary table extension header. 


The remaining keywords described in this section are required by the AXAF ray 
trace standard in order to provide a description of the data file. It is important 
that these keywords be maintained so that each data file contains information 
about its own content. As much as possible, these keywords have been chosen 
from keywords currently in common use. The keywords are as follows: 


EXTNAME this FITS reserved keyword shall contain the string ‘RAYTRACE’ 
identifying this binary table extension as one which contains the result of ray 
trace modeling. 

RTVER shall contain an integer 1, which signifies that this file conforms to the 
current version (v 1) of the AXAF raytrace standard. 

ORIGIN shall contain a string identifying the organization creating the FITS 
file. The keyword is a FITS reserved keyword and is duplicated from the 
primary header. 

OBSERVER shall contain a string identifying the person generating the ray 
trace. The keyword is a FITS reserved keyword and is duplicated from the 
primary header. 
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DATE-OBS, TIME-OBS The DATE-OBS, and TIME-OBS traditionally refer 
to date and time of observation; for ray trace, they will refer to the date and 
time of the original simulation. By FITS convention, dates and times are 
specified as ’dd/mm/yy’ and ’hh:mm:ss’ in Universal Time. The keywords 
are duplicated from the primary header. 

TELESCOP shall specify the name of the telescope model used for the ray trace. 
The keyword is duplicated from the primary header. 

PROGNAME shall specify the name of the ray trace program. The keyword is 
duplicated from the primary header. 

OBJECT shall specify the object modeled (e.g., ‘POINT SOURCE’). The key- 
word is duplicated from the primary header. 

TFIELDS this keyword shall contain an integer specifying the number of fields 
contained in the data array. 

TTYPEn these keywords shall be character strings specifying the name of data 
field n (e.g., ‘RT_X’). n shall be a value in the range 1 . . . TFIELDS. 

TFORMn these keywords shall contain character strings specifying the data type 
of field n (e.g., ‘D’ for double precision, ‘J’ for 32-bit integer), n shall be a 
value in the range 1 . . . TFIELDS. 

TUNITn these keywords shall contain character strings specifying the physi- 
cal units of field n (e.g., ‘mm’, ‘KeV’). n shall be a value in the range 
1... TFIELDS. 


2.2.2 Raytrace Header Optional Keywords 

At present, the AXAF ray trace standard defines no optional keywords for the ray 
trace binary extension header. 


2.3 Required Photon Event Fields 

Table 3 summarizes the required fields for the RAYTRACE binary extension. 
An example of their definition within the FITS extension header is given in Ap- 
pendix B. These keywords were chosen to represent quantities currently used or 
anticipated to be useful within the AXAF community. The names are prefixed 
with “RT_” to signify raytrace quantities and to prevent clashes with FITS fields 
used in other extensions. The units and axes were chosen to conform as much as 
possible to common usage. 
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Field Name 

Type 

Units 

Description 

RT_X 

double 

mm 

X Position 

RT.Y 

double 

mm 

Y Position 

RT_Z 

double 

mm 

Z Position 

RT.COSX 

double 

- 

X direction cosine 

RT.COSY 

double 

- 

Y direction cosine 

RT.COSZ 

double 

- 

Z direction cosine 

RT_KEV 

double 

KeV 

Energy of photon 

RT.WGHT 

double 

cm**2 

Statistical weight of ray 

RT.ID 

32-bit 

- 

Photon ID number from ray trace 


Table 3: Photon fields required by the AXAF ray trace standard 


All fields listed in Table 3 shall be required even if they are of constant value (e.g., 
RT_KEV = 1.0, RT_Z = 0.0). This allows the standard to be used by the most 
rudimentary FITS readers. 


2.3.1 Coordinate System and Units 

Positions and directions within the AXAF ray trace standard shall be defined 
according to a right-handed coordinate system with the following properties: 

• The Z axis is co-incident with the optical axis of a perfect system. 

• A standard origin of the coordinate system shall be defined for each optical 
system modeled. For all AXAF optics, the XY plane shall be defined as the 
plane bisecting the AXAF Central Aperture Plate (CAP). 

• The rays travel in the positive 2 direction. Thus a typical object to be imaged 
will have a large negative 2 coordinate. 

• The Y axis shall be aligned with the “vertical axis” with positive y cor- 
responding with “up” and negative y corresponding with “down.” Where 
appropriate, “down” is defined as the direction of gravity. 

The AXAF ray trace standard has not adopted AXAF spacecraft coordinates ( 
“forward” is positive X , “down” is positive Z ). The spacecraft coordinates were 
chosen according to standard aeronautical practices, but conforms to neither stan- 
dard optical practices nor standard astronomical practices. In order to minimize 
confusion, the AXAF ray trace standard has chosen a coordinate system in com- 
mon use by the raytracing community. 

Several quantities associated with X-ray photon events have associated physical 
dimensions. The AXAF ray trace standard shall specify a particular choice of 
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units. It is felt that allowing arbitrary units would add unnecessary complexity to 
the ray trace standard and to any FITS reader used to read the standard. 


2.3.2 Photon Position: RT_X, RT_Y, RT_Z 

The position of each photon shall be stored as three IEEE double precision numbers 
and be in fields named RTJX, RT_Y, and RT_Z. In keeping with the standard 
practice in Optical Engineering, the positions of each individual rays shall be stored 
in units of millimeters (mm). 


2.3.3 Photon Direction: RT_COSX, RT_COSY, RT.COSZ 


The direction of each photon ray shall be stored as three IEEE double precision 
numbers and be in fields named RT_COSX, RT_COSY, and RT_COSZ. These 
numbers are dimensionless and defined to be the cosine of the angle between the 
photon ray and the x, y, and 2 coordinate axes, respectively. 


2.3.4 Photon Energy: RTJKEV 

The energy of each photon shall be stored as an IEEE double precision number 
and be in a field named RTJKEV. This number shall have units of KeV. This 
quantity can be converted to wavelength using the equation A = he/ E where 
A is the wavelength, h = 4.135669 x 10 -18 KeV s is Plank’s constant, and c = 
2.99792458 x 10 8 ms" 1 . 

If the ray trace modeling software does not give energies, a canonical value of 
RTJKEV = 0.0 should be used. 


2.3.5 Statistical Weight: RT_WGHT 

The statistical weight of each photon event shall be stored as an IEEE double 
precision number and be in a field named RT_WGHT. This number has units of 
square centimeters. This value is defined by the following identity: 

N 

^2 RT_WGHT, = A (1) 

1 

Namely the sum of the statistical weights give the effective area (in square cen- 
timeters) of the optic modeled by the ray trace. 


8 



If the ray trace modeling software does not generate statistical weights, the value 
A/N, (i.e. effective area divided by number of rays) should be used. 


2.3.6 Photon Identifier: RTJD 

Each ray in the event list shall have an identifier stored as a 32-bit integer and be 
in a field named RTJD. The AXAF ray trace standard makes no requirement for 
the RTJD field aside from its existence. 


2.4 Optional Photon Event Fields 


Field Name 

Type 

Units 

Description 

RT_LEN 

double 

mm 

Path length of Ray 

RT.STK1 

double 

- 

SI Stokes Parameter (Polarization) 

RT.STK2 

double 

- 

S2 Stokes Parameter (Polarization) 

RT_STK3 

double 

- 

S3 Stokes Parameter (Polarization) 

RT.TIME 

double 

s 

Simulated arrival time 

RT_ALPn 

double 

rad 

grazing angles 

RT_MP 

int 

- 

mirror pair of ray 


Table 4: Optional photon fields AXAF ray trace standard 


Table 4 lists the optional fields that may be included or left out. If the field is not 
present, the canonical value may be assumed. 


2.4.1 Path Length: RTJLEN 

The optical path length of each ray shall be stored as an IEEE double precision 
number and be in a field named RTXEN. This number has units of millimeters. It 
is defined as the distance the ray has traveled from an arbitrary plane perpendicular 
to the optical axis. This value may also be converted the optical phase of the ray. 

A canonical value of 0.0 may be used for event lists where there is no associated 
optical path length information. 


2.4.2 Photon Polarization: RT_STK1, RT-STK2, RT_STK3 

The polarization of each ray shall be stored as three IEEE double precision num- 
bers and be in fields named RT_STK1, RT.STK2, and RT_STK3. These fields 
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correspond to the Stokes parameters sj, s 2 , and S3 modified to be dimensionless. 

The standard definition of Stokes parameters have units of electric field intensity. 
For ray traces of polarized photon events, the AXAF ray trace standard shall 
require that the polarization fields obey the relation 

RT.STK1 2 + RTJSTK2 2 + RTJ5TK3 2 = 1 (2) 


Unpolarized light is characterized by 


si = s 2 = s 3 = 0. (3) 

A canonical value of 0.0 should be used for event lists where there is no associated 
polarization information. 

A full description of the Stokes parameters may be found in Appendix A. 


2.4.3 Arrival Time: RT.TIME 


The simulated arrival time shall be stored as an IEEE double precision number 
and be in a field named RT.TIME. This field has units of seconds and shall time 
tag the arrival of a ray. The beginning of the ray trace shall be RT.TIME of 0.0. 
This field has no default value. 


2.4.4 Grazing Angles: RT_ALPn 

The grazing angles aj, a 2, . . . , a n shall be stored as IEEE double precision numbers 
in the fields named RT.ALP1, RT.ALP2, ..., RT_ALPn. The grazing angles are 
measured in radians and defined as the angle between the incident ray and the 
tangent to each mirror surface. Thus, for X-rays, each grazing angle will be a 
small number close to 0.0 (as opposed to a number near 7r/2). The angles are 
numbered such that ai is the first reflection the ray encounters while propagating 
from the source. 


2.4.5 Mirror Pair Index: RT.MP 

Each ray in the event list may also be tagged by a mirror pair index. This index 
shall be stored as a 32-bit integer in the field named RT_MP. This field will be 
used to allow the resulting rays from a ray trace to be separated according to the 
component of the optics with which they interacted. 


10 



3 Future Extensions 


The AXAF ray trace standard will be maintained by the AXAF SSWG and may 
ultimately be adopted by the AXAF Science Center (ASC). The maintainer of 
the standard shall be responsible for documenting extensions to the standard. 
Extensions to the ray trace standard may consist of additional optional fields to 
the RAYTRACE binary table array. Additional SIMULATION extensions may 
also be defined to accommodate simulated instrument responses. 


3.1 Extensions to RAYTRACE 

Optional keywords and data fields may be added to the RAYTRACE standard. 
It is strongly recommended that new field names all be prefixed with the string 
‘RT_’ to signify ray trace data. It is important to avoid field name clashes with 
field names currently in use to archive real X-ray data. 

Essential housekeeping information that is specific to a software package may be 
passed in an optional field named “RT_[package].” For example, CYGNUS may 
have a field named “RT.CYGNU” to pass CYGNUS specific data. Use of such 
fields should be minimized since they decrease the portability of the ray trace data. 

The maintainer of the standard shall make every effort to incorporate new optional 
keywords and fields that the community finds useful. 


3.2 Extensions to SIMULATION 


The FITS standard allows a data file to contain many extensions, each of which is a 
separate block of data. The AXAF ray trace standard has defined a block named 
RAYTRACE within a SIMULATION FITS file. It would be natural to define 
additional types of data blocks which can accommodate the results of simulated 
science instrument responses to ray trace inputs. Data blocks may also be used to 
record ancillary data about the ray trace (e.g., source spectrum, source geometry, 
optical constants). The feasibility and desirability of such future standards should 
be explored. 
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A Stokes Parameters 


It is common practice in the study of optics and radiative processes to characterize 
polarization in terms of a set of four Stoke’s parameters. The term “Stoke’s pa- 
rameters” refer to a class of parameterization schemes rather than a single unique 
parameterization. In particular, there is neither a consistent normalization nor a 
consistent sign convention to specify the helicity of a ray. For the AXAF ray trace 
standard, we have no meaningful measure of intensity and we shall impose a nor- 
malization to unity. For the helicity we have chosen to follow a parameterization 
scheme that seems to be more popular within the radio and optical polarimetry 
community. This convention is described in Jackson’s Classical Electrodynamics. 
and Hecht and Zajac’s Optics. The standard is opposite the convention found in 
Born and Wolf. 

Specifically, imagine a plane wave propagating in the positive z direction. The x 
direction shall be defined as the projection of the AXAF ray trace x-axis upon the 
plane normal to the incident ray. The x and y components of the electric field can 
then be described as 


E x = a 1 e i ( kz ~“ t+s >), (4) 

E y = a 2 e i V cz - ut+s >\ (5) 

Then the four Stokes parameters are defined as 

■So = cti 2 + a??, (6) 

5a = ai 2 - a2 2 , (7) 

s 2 = 2aia 2 cos(<$ 2 — <5i), (8) 

s 3 = 2aja 2 sin(<5 2 — 6i), (9) 


One can also parameterize the electric field in terms of helicity. A wave with pos- 
itive helicity appears to rotate counter-clockwise to an observer being approached 
by the wave. Positive helicity is also referred to as right-handed circular polariza- 
tion and left circular polarization. With the electric field parameterized as: 


E+ = a + e^ kz ~ wt+s+ \ (10) 

E- = a^e i{kz - wi+s -\ ( 11 ) 

Then the four Stokes parameters are defined as 

50 = a + 2 + a_ 2 , (12) 

51 — 2a + a_ cos(£_ — £+), (13) 

s 2 = 2a + a_ sin(<5_ — 6 + ), (14) 

s 3 = a+ 2 -a_ 2 , (15) 
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For a wave traveling in the +z direction, the definitions chosen have the following 
physical interpretations: 


(si,S2) 5 3) — ( + 1)0,0) 

(si,-s 2 ,s 3 ) = (-1.0,0) 

(Sl,S2) 5 3) = (0,+l,0) 

(S1,S2,3 3 ) = (0,"1,0) 

(Si,S 2 ,5 3 ) = (0,0, +1) 

(si,s 2 ,s 3 ) = (0,0, -1) 


linearly polarized in x direction 
linearly polarized in y direction 
linearly polarized in x + y direction 
linearly polarized in x — y direction 
pure positive helicity 
pure negative helicity 


The polarization of rays stored in the AXAF ray trace standard shall be described 
by three Stoke’s parameters stored in the data fields named RTJSTKl, RT.STK2, 
and RT_STK3. These three values shall correspond to (si,s 2 ,S 3 ) normalized so 
that S\^ + + >s 3 ^ = 1. 

In the astronomical literature, (s 0 , si, s 2 , s 3 ), are often denoted as ( I,Q,U,V ) and 
use a coordinate system aligned with the celestial declination and right ascension 
axes. We have chosen to forgo this nomenclature in order to avoid confusion. 
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B Sample FITS headers 


The listing of the primary header for this FITS file follows: 


$j|e3|c24c3|(:4cjtc3fc3tc3|c)fcjt($jtntc){e3{c’|c$$)|'$’f (3 4 e3 4 e ************** 


SIMPLE = T / 
BITPIX = 8 / 
NAXIS = 0 / 
EXTEND = T / 


file does conform to FITS standard 
number of bits per data pixel 
number of data axes 
FITS dataset may contain extensions 


CONTENT = 'SIMULATION 5 
ORIGIN = 5 SA0 
0BSERVER= ’hsieh' 

DATE = 5 01/03/93 5 
TELESC0P= 'S-AXAF 5 
PR0GNAME= 5 OSAC 5 
OBJECT = 'pointsource 5 
DATE-0BS= 5 01/03/93 5 
TIME-0BS= ’21: 11:36’ 


/ file contains simulated data 
/ origin of FITS file: NASA/GSFC 
/ person creating ray trace 
/ FITS file creation date (dd/mm/yy) 

/ Modeled telescope: simulated AXAF 
/ ray trace program: OSAC 
/ name of observed object 

/ U.T. date of observation start (dd/mm/yy) 
/ U.T. time of observation start (hh:mm:ss) 


HISTORY OSAC vl.O 1-MAR- 1993 run with foo source parameters \ 

HISTORY and bar mirror parameters 

HISTORY FITOSAC vO.l l-MAR-1993 applied vignetting with foo parameters 
END 


The listing of the secondary header for this FITS file follows: 


$3{t!|c3|c$3t:)|c]i:)fe3|c?|c3|c]t(?|o|c34c:4ntc**************************** 


XTENSI0N= 

’BINTABLE 5 

BITPIX = 


NAXIS 


NAXIS1 = 


NAXIS2 = 


PC0UNT = 


GCOUNT = 


EXTNAME = 

5 RAYTRACE 5 

ORIGIN - 

5 SAO 

0BSERVER= 

’hsieh 5 

TELESC0P= 

5 S- AXAF 5 

PR0GNAME= 

'OSAC 

OBJECT = 

'pointsource 

DATE-0BS= 

'01/03/93' 

TIME-0BS= 

'21:11:36' 

TFIELDS = 


TTYPE1 = 

'RT_X 


/ binary table extension 
8 / 8-bit bytes 

2 / 2-dimensional binary table 
100 / width of table in bytes (12*8+1*4) 

30 / number of rows in table 

0 / size of special data area 

1 / one data group (required keyword) 

/ name: table of ray trace photon events 
/ origin of FITS file: NASA/GSFC 
/ person creating ray trace 
/ Modeled telescope: simulated AXAF 
/ ray trace program: OSAC 
/ name of observed object 

/ U.T. date of observation start (dd/mm/yy) 
/ U.T. time of observation start (hh:mm:ss) 
13 / number of fields in each row 
/ X Position 
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TF0RM1 

= 

’D 

/ X Position 

TUNIT1 

S 

’mm ’ 

/ X Position 

TTYPE2 

= 

’RT_Y * 

/ Y Position 

TFORM2 

= 

’D 

/ Y Position 

TUNIT2 

= 

’mm ’ 

/ Y Position 

TTYPE3 

= 

’RT_Z ’ 

/ Z Position 

TF0RM3 

= 

’D 

/ Z Position 

TUNIT3 

S 

’mm ’ 

/ Z Position 

TTYPE4 

= 

’RT.COSX ’ 

/ X direction cosine 

TFORM4 

= 

’D 

/ X direction cosine 

TUNIT4 

= 

> J 

/ X direction cosine 

TTYPE5 

= 

’RT.COSY ’ 

/ Y direction cosine 

TFORM5 

= 

’D ’ 

/ Y direction cosine 

TUNIT5 

= 

> J 

/ Y direction cosine 

TTYPE6 

= 

’RT.COSZ ’ 

/ Z direction cosine 

TFORM6 

s 

’D ’ 

/ Z direction cosine 

TUNIT6 

= 

) J 

/ Z direction cosine 

TTYPE7 

= 

’RT.KEV ’ 

/ Energy of photon 

TF0RH7 

= 

’D ’ 

/ Energy of photon 

TUNIT7 

= 

’KeV ’ 

/ Energy of photon 

TTYPE8 

= 

’RT.WGHT ’ 

/ Statistical weight of ray 

TF0RM8 

=s 

’D ’ 

/ Statistical weight of ray 

TUNIT8 

= 

’cm**2 ’ 

/ Statistical weight of ray 

TTYPE9 

= 

’RT_ID ’ 

/ Arbitrary ID 

TFDRM9 


’J ’ 

/ Arbitrary ID 

TUNIT9 

= 

> ) 

/ Arbitrary ID 

TTYPE10 

= 

’RT.LEN ’ 

/ Path Length of Ray 

TFORMIO 

= 

’D ’ 

/ Path Length of Ray 

TUNITIO 

= 

’mm ’ 

/ Path Length of Ray 

TTYPE11 

= 

’RT.STKl ’ 

/ Si Stokes Parameter (Polarization) 

TF0RM11 

= 

’D ’ 

/ SI Stokes Parameter (Polarization) 

TUNIT11 

= 

> J 

/ SI Stokes Parameter (Polarization) 

TTYPE12 

= 

^RT.S^ J 

/ S2 Stokes Parameter (Polarization) 

TFORM12 


>D 

/ S2 Stokes Parameter (Polarization) 

TUNIT12 

= 

) > 

/ S2 Stokes Parameter (Polarization) 

TTYPE13 

= 

’RT.STK3 ’ 

/ S3 Stokes Parameter (Polarization) 

TFORM13 

= 

’D ’ 

/ S3 Stokes Parameter (Polarization) 

TUNIT13 

END 

s 

1 > 

/ S3 Stokes Parameter (Polarization) 
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C HISTORY keyword 


The AXAF ray trace standard keeps a log of all software that has operated upon 
the photon event list. This log is maintained by appending HISTORY keywords 
to the the primary header of the FITS file. In this section, we tabulate the content 
and format that various software packages use to log history information. 


C.l 

CYGNUS 

C.2 

IRT 

C.3 

MIRROR 

C.4 

OSAC 
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